In the first implementation of the GM-to-AUTOSAR transformation, we used
two ATL matched rules, 9 functional helpers and 6 attribute helpers to implement
the required mapping between the two metamodels. After reimplementing the
transformation to be completely declarative, the new transformation was composed
of three matched rules and two lazy rules. Although we had to reimplement the
transformation to use the verification prototype, we point out that the new
declarative implementation is simpler and more readable. The rules implemented
are listed in Table~\ref{tab:rulesUsedinMT} together with the types of the
rules, the input element matched by the rule, and the output elements generated
by the rule.
\begin{table}[tbh]%tbh !h
%\vspace{-0.6cm}
 	\centering
 	\scriptsize
 	\renewcommand{\arraystretch}{1.9}
\begin{tabular}{|l|l|l|l|}
 \hline %ALL WAS 0.TWENTYTWO
 \parbox{0.15\textwidth}{\it{\bf Rule Type}} &
 \parbox{0.26\textwidth}{\it{\bf Rule Name}}&
 \parbox{0.14\textwidth}{\it{\bf Input Types}} &
 \parbox{0.43\textwidth}{\it{\bf Output Types}}\\ \hline
 %%
 \parbox{0.15\textwidth}{Matched Rule} & 
 \parbox{0.26\textwidth}{$\mathtt{createComponent}$}&
 \parbox{0.14\textwidth}{\emph{Module}}&
 \parbox{0.43\textwidth}{\emph{SwCompToEcuMapping\_component,
 ComponentPrototype}}
 \\
 \hline
 %%
 \parbox{0.15\textwidth}{Matched Rule} & 
 \parbox{0.26\textwidth}{$\mathtt{initSysTemp}$}&
 \parbox{0.14\textwidth}{\emph{PhysicalNode}}&
 \parbox{0.43\textwidth}{\emph{System, SystemMapping, SoftwareComposition,
 CompositionType, EcuInstance}}
 \\
 \hline
 %%
 \parbox{0.15\textwidth}{Matched Rule} & 
 \parbox{0.26\textwidth}{$\mathtt{initSingleSwc2EcuMapping}$}&
 \parbox{0.14\textwidth}{\emph{Partition}}&
 \parbox{0.43\textwidth}{\emph{SwcToEcuMapping}} \\ \hline 
 %%
 \parbox{0.15\textwidth}{Lazy Rule} & 
 \parbox{0.26\textwidth}{$\mathtt{createPPort}$}&
 \parbox{0.14\textwidth}{\emph{Scheduler}}&
 \parbox{0.43\textwidth}{\emph{PPortPrototype}} \\ \hline 
 %%
 \parbox{0.15\textwidth}{Lazy Rule} &
 \parbox{0.26\textwidth}{$\mathtt{createRPort}$}&
 \parbox{0.14\textwidth}{\emph{Scheduler}}&
 \parbox{0.43\textwidth}{\emph{RPortPrototype}} \\ \hline 
 \end{tabular}
\caption{The types of ATL constructs used to reimplement the transformation,
their designated names, and their input and output element types.}
\label{tab:rulesUsedinMT}
\vspace{-0.3cm}
\end{table}
% The matched rule $\mathtt{initSysTemp}$ maps
% a \emph{PhysicalNode} element to a \emph{System} element, a \emph{SystemMapping}
% element, a \emph{SoftwareComposition} element, a \emph{CompositionType}
% element, and an \emph{EcuInstance} element. The matched rule
% $\mathtt{initSysTemp}$ also calls the two lazy rules ($\mathtt{createPPort}$
% and $\mathtt{createRPort}$) to create \emph{PPortPrototype}s and \emph{RPortPrototype}s, and assigns the
% generated ports to the \emph{port} association of the created
% \emph{CompositionType} element.
% 
% The matched rule $\mathtt{createComponent}$ maps \emph{Module} elements to
% \emph{ComponentPrototype} elements. 
% 
% The matched rule $\mathtt{initSingleSwc2EcuMapping}$ maps a
% \emph{SwcToEcuMapping} element to a \emph{SwcToEcuMapping} element.
%

As described in~\cite{ECMFApaper}, the relationships between the outputs of the
matched rules are built using the ATL predefined function
$\mathtt{resolveTemp}$. The $\mathtt{resolveTemp}$ function allows a rule to
reference the elements that are yet to be generated by another rule at runtime.
For example, the $\mathtt{resolveTemp}$ function was used to connect the
\emph{SwcToEcuMapping} elements created by the
$\mathtt{initSingleSwc2EcuMapping}$ matched rule to the \emph{SystemMapping}
element created by the $\mathtt{initSysTemp}$ matched rule. Further, the matched
rule $\mathtt{initSysTemp}$ calls the two lazy rules and assigns the union of
the lazy rules' outputs to the \emph{ports} of the \emph{CompositionType}
produced by the $\mathtt{initSysTemp}$ rule.
